Fix market order price rounding for builder-deployed perp dexs - #311
Fix market order price rounding for builder-deployed perp dexs#311pucedoteth wants to merge 2 commits into
Conversation
_slippage_price classifies an asset as spot with `asset >= 10_000`, but builder-deployed (HIP-3) perp dex assets start at 110000, so they are also caught by that check. Those perps are then rounded to 8 - szDecimals decimals instead of 6 - szDecimals, and market_open/market_close can produce a price with too many decimal places, which the exchange rejects. Spot asset ids live in [10000, 110000), so bound the check on both sides.
46522b3 to
8f283b8
Compare
koriyoshi2041
left a comment
There was a problem hiding this comment.
Verified at 8f283b807d. The range matches Info's asset-ID layout: 109999 retains spot precision (0.0012963) while 110000 switches to perp precision (0.001296). The full test suite passes locally (39/39) on Python 3.11, and git diff --check is clean. The focused regression also fails on master and passes here.
One non-blocking test improvement would be to assert both adjacent boundary IDs in the regression, but the implementation is correct as written.
Per review: the regression asserted only that asset 110000 rounds as a
perp. Asset 109999 is the last spot id, so asserting it keeps spot
precision fixes the other end of the same boundary.
The two assertions fail independently, which is the point:
is_spot = asset >= 10_000 (the original bug)
-> 110000 assertion fails, 109999 still passes
is_spot = 10_000 <= asset < 109_999 (upper bound off by one)
-> 109999 assertion fails, 110000 still passes
39/39 pass.
|
Thanks for the review, and for reproducing it independently. Took the test suggestion: the regression now asserts asset 109999 keeps spot precision ( They fail independently, which is what makes the pair worth having:
39/39 still pass. |
Problem
Exchange._slippage_pricedecides how many decimal places a market-order price may have:Spot asset ids are
index + 10000, but builder-deployed (HIP-3) perp dex asset ids are110000 + i * 10000 + index(seeInfo.__init__). Those are also>= 10_000, so every HIP-3 perp is classified as spot and rounded to8 - szDecimalsdecimals instead of6 - szDecimals.market_open/market_closeon a HIP-3 dex can therefore build a price with more decimal places than perps allow, and the exchange rejects the order. For an asset withszDecimals == 0and a mid of0.0012345678, a 5% buy slippage price comes out as0.0012963(7 decimals) where the perp limit is 6.#225 fixed the
all_midslookup for HIP-3 dexs but left this check untouched.Fix
Spot asset ids live in
[10000, 110000), so bound the check on both sides:Tests
Adds
tests/exchange_test.pycovering_slippage_pricefor a perp, a spot pair, and a builder-deployed perp asset. The last one fails onmaster(0.0012963 != 0.001296) and passes with the fix. The existing suite still passes (39 tests).